fix: check container runtime is available in stop and restart - #1036

helix logs and helix status shell out to the container runtime without
checking that it can be spawned, so on a host that has podman but not
docker they fail with a bare "No such file or directory (os error 2)".
helix start and helix stop on the same host report that Docker is not
installed and suggest setting container_runtime = "podman" instead.

#1036 gave stop and restart that message by calling check_available.
logs and status were deliberately left out, because check_available
auto-starts the daemon and that is the wrong side effect for a read-only
command. This keeps that constraint rather than reversing it, and maps
the spawn failure through not_installed_error, the helper
check_available already uses to build the message. It runs only when the
process could not be spawned at all, so nothing is probed and nothing is
started. A runtime that is installed but not running still spawns and
returns a non-zero status, so the existing error paths are unchanged.

The originating os error is preserved as the cause line.

on a host that has podman but not docker, `helix logs` and `helix
status` both die with `Failed to read logs for helix-x-dev: No such file
or directory (os error 2)`. `helix start` and `helix stop` on that same
box give you `Docker is not installed` plus a help line telling you to
set `container_runtime = "podman"` in helix.toml. same machine, same
missing binary, two completely different errors.

#1036 fixed stop and restart by calling `check_available` first. logs
and status were left out of that one on purpose, since `check_available`
auto starts the daemon and doing that as a side effect of a read only
command is wrong. that reasoning still holds, so this doesn't touch
`check_available`.

instead it routes the spawn failure through `not_installed_error`, which
is the helper `check_available` already uses to build that message and
the only place it was ever called from. it only fires when the process
could not be spawned at all, so nothing gets probed and nothing gets
started. if the binary is there and the daemon is just down, `docker
logs` still spawns fine and returns non zero, so the existing error
paths are untouched.

two lines of src, the rest is the test.

before

```
Failed to inspect helix-repro1036-dev: No such file or directory (os error 2)
Failed to read logs for helix-repro1036-dev: No such file or directory (os error 2)
```

after

```
error: Docker is not installed (`docker` not found on PATH)

   │ No such file or directory (os error 2)

   = help: Podman is installed — set `container_runtime = "podman"` under [project] in helix.toml to use it instead, or install Docker.
```

the underlying os error is kept as the cause line, so nothing is lost.

the test points `HELIX_TEST_CONTAINER_RUNTIME_BIN` at a path that
doesn't exist, which is the same spawn failure a missing docker gives,
and checks that logs, status and stop all name the runtime and all still
carry the os error. stop is in that loop on purpose, so if someone
changes one of the three later the other two don't quietly drift again.

`prune_instance` reaches the same bare error through `remove_container`.
left it out to keep this focused, happy to do it separately if you want
it.

tests

```
cargo test -p helix-cli --test runtime_commands
cargo clippy -p helix-cli --all-targets -- -D warnings
cargo fmt --all -- --check
```


<!-- greptile_comment -->

<h3>Greptile Summary</h3>

The PR improves missing-container-runtime diagnostics for the read-only
logs and status commands without probing or starting the daemon.
- Routes logs and status spawn failures through the shared
runtime-not-installed diagnostic.
- Adds a missing-runtime fixture and regression coverage across logs,
status, and stop.
- The new mapping also labels non-missing-binary spawn failures as
installation failures.

<details><summary><h3>Important Files Changed</h3></summary>




| Filename | Overview |
|----------|----------|
| crates/cli/src/local_runtime.rs | Improves missing-runtime errors for
logs and status, but unconditionally misclassifies every spawn failure
as a missing binary. |
| crates/cli/tests/runtime_commands.rs | Adds focused regression
coverage confirming logs, status, and stop identify a missing Docker
executable while retaining the OS error. |
| crates/cli/tests/support/mod.rs | Adds a fixture helper that reliably
directs runtime commands to a nonexistent executable. |

</details>

<sub>Reviews (1): Last reviewed commit: ["fix: name the missing
container runtime
..."](d20a3c7)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=57831448)</sub>

> Greptile also left **1 inline comment** on this PR.

<!-- /greptile_comment -->